home *** CD-ROM | disk | FTP | other *** search
/ BCI NET / BCI NET Dec 94.iso / archives / programming / utilities / stackcheck.lha / StackCheck / StackCheck.dok < prev    next >
Encoding:
Text File  |  1993-05-05  |  11.9 KB  |  272 lines
  1.                        StackCheck 1.0
  2.                   geschrieben von Günther Röhrich
  3.                   dieses Programm ist Public Domain
  4.  
  5.  
  6. EINLEITUNG
  7.  
  8. StackCheck ist ein Programm, das den maximalen Verbrauch an Stapelspeicher
  9. (Stack) eines anderen Programms bestimmen kann. Es arbeitet nach einer ganz
  10. anderen Methode als alle anderen Stackanzeiger wie z.B. WatchStack oder Xoper.
  11. Dieses Programm ist ausschließlich für Entwickler gedacht, die den Stapel-
  12. verbrauch ihrer Programme untersuchen wollen.
  13.  
  14. VORTEILE
  15.  
  16. - Es wird der tatsächliche maximale Stapelverbrauch angezeigt, und nicht
  17.   der Maximalwert von einer Vielzahl von Einzelmessungen. Daher werden auch
  18.   sehr kurze Spitzenwerte im Stapelverbrauch erfaßt. (Unter "Spitzenwert"
  19.   verstehe ich einen Stapelverbrauch, der nur wenige Taktzyklen dauert)
  20.  
  21. - StackCheck braucht nicht während der ganzen Laufzeit eines Programms aktiv
  22.   zu sein. Es genügt, wenn es beim Starten des Programms sowie kurz vor der
  23.   Beendigung aktiv ist.
  24.  
  25. - Der Stapelverbrauch wird auch dann korrekt erfaßt, wenn das zu unter-
  26.   suchende Programm das Multitasking während seiner Laufzeit zwischen-
  27.   zeitlich abschaltet.
  28.  
  29. - Bei Programmen, die von der Workbench aus gestartet wurden, genügt es sogar
  30.   wenn StackCheck kurz vor der Beendigung des Programms aktiv war. Der
  31.   maximale Stapelverbrauch wird trotzdem korrekt ermittelt.
  32.  
  33. NACHTEILE
  34.  
  35. - Der Stapelverbrauch kurz nach Beginn und kurz vor dem Ende eines Programms
  36.   kann nicht erfaßt werden. (Unter "kurz" verstehe ich ca. 0,04 Sekunden)
  37.   Ausnahme: Bei Programmen, die von der Workbench aus gestartet wurden,
  38.   wird der Stapelverbrauch auch unmittelbar nach Beginn korrekt erfaßt.
  39.  
  40. - Unter Kickstart 1.2/1.3 können keine Programme untersucht werden, die vom
  41.   CLI/Shell aus gestartet wurden. (siehe später) 
  42.  
  43. - Ab Kickstart 2.0 können keine BCPL-Programme mit StackCheck untersucht
  44.   werden. (Es kommt dabei höchstwahrscheinlich zu einem Absturz)
  45.  
  46.  
  47. BENÖTIGTER COMPUTER/BETRIEBSSYSTEM
  48.  
  49. StackCheck läuft auf allen AMIGAs mit allen Kickstart-Versionen und mit allen
  50. Prozessoren.
  51. Getestete Konfigurationen:
  52.  
  53. A500  Kickstart 2.04/1.3  Prozessor: 68000
  54. A1200 Kickstart 3.00      Prozessor: 68EC020
  55. A3000 Kickstart 2.04      Prozessor: 68030
  56.  
  57.  
  58. BENUTZUNG VON STACKCHECK
  59.  
  60. Die Syntax von Stackcheck lautet:
  61.  
  62.  StackCheck Name|* [DELAY=n][PRI=n][STACK=n][NUM=n]
  63.  
  64. Ein Abbruch ist durch Drücken von CTRL-C jederzeit möglich.
  65.  
  66. Name
  67.  
  68. Der Name des zu untersuchenden Programmes muß als erstes Argument angegeben
  69. werden. Es wird auf Groß- und Kleinschreibung geachtet. Wenn der Name Leer-
  70. zeichen enthält muß er in Hochkommas angegeben werden. Das Zeichen "*" steht
  71. für jeden beliebigen Namen. Wildcards werden nicht unterstützt.
  72.  
  73. Alle anderen Optionen sind wahlfrei. Werden sie weggelassen wird ein inter-
  74. ner Defaultwert benützt. Für n muß eine Zahl eingegeben werden.
  75. (z.B. stack=20000) 
  76.  
  77.  
  78. DELAY=n
  79.  
  80. n gibt die Zeitspanne zwischen zwei Überprüfungen des Stapels an. Die
  81. Einheit ist eine 1/50 Sekunde. Der Defaultwert ist 2.
  82.  
  83.  
  84. PRI=n
  85.  
  86. Setzt die Taskpriorität von StackCheck auf n. Der Defaultwert ist 1.
  87.  
  88.  
  89. STACK=n
  90.  
  91. Es wird nur ein Programm untersucht, dessen Stapelgröße gleich n ist.
  92. (Nützlich wenn "*" als Name angegeben wurde)
  93.  
  94.  
  95. NUM=n
  96.  
  97. Es wird nur ein Programm untersucht, dessen CLI-Nummer gleich n ist. Die Nummer
  98. des CLI wird normalerweise im CLI/Shell-Prompt angegeben.
  99. (Nützlich wenn "*" als Name angegeben wurde)
  100.  
  101.  
  102. ARBEITSWEISE VON STACKCHECK
  103.  
  104. Bemerkung: Wer mit der Funktionsweise des Prozessorstapels nicht vertraut ist,
  105. der sollte sich vorerst das Kapitel "Arbeitsweise des Stapels" durchlesen.
  106.  
  107. Die Arbeitsweise von StackCheck beruht darauf, daß der noch unbenutzte Bereich
  108. des Stapels mit dem Füllmuster $BEEF aufgefüllt wird. Wenn ein Programm mehr
  109. Stapelspeicher benutzt wird das Füllmuster beschädigt. Um den maximalen Ver-
  110. brauch an Stapelspeicher festzustellen genügt es somit abzuzählen, bis wohin
  111. das Füllmuster noch nicht überschrieben wurde. Da es jedoch nicht bekannt ist,
  112. wann das Programm beendet wird, muß diese Messung ständig wiederholt werden.
  113. Was zählt ist das Ergebnis der letzten Messung.
  114.  
  115. Beim Start von StackCheck wird als erstes untersucht, ob das Programm bereits
  116. läuft. Wenn nicht wird eine bestimmte Zeitspanne gewartet und es wird dann
  117. erneut geprüft, ob das Programm in der Zwischenzeit gestartet wurde.
  118. (Die Zeitspanne kann durch die DELAY-Option eingestellt werden)
  119.  
  120. Wenn das gesuchte Programm gefunden ist, wird der Zustand der ersten zwei
  121. Worte am Stapelende untersucht. (Stapelende = unteres Ende des Stapels)
  122. Wenn das Füllmuster $BEEF gefunden wurde wird nichts weiter getan. Wenn
  123. lauter Nullen gefunden werden, so wurde das Programm höchstwahrscheinlich
  124. von der Workbench aus gestartet. Zu Beginn des Programms war der Stapel
  125. daher komplett mit Nullen aufgefüllt. Es werden dann alle Nullen beginnend
  126. vom unteren Ende des Stapels durch das Füllmuster $BEEF ersetzt. Sobald
  127. das erste Wort gefunden wurde, das nicht Null enthält, wird dieser Vorgang
  128. abgebrochen. Dies ist gleichzeitig die Stelle des bisherigen maximalen
  129. Stapelverbrauchs. Der Füllvorgang wird jedoch höchstens bis zum aktuellen
  130. Stapelzeiger durchgeführt, um das Programm nicht zu beeinträchtigen.
  131. Wenn die ersten zwei Worte am unteren Ende des Stapels eine unbekannte
  132. Bytekombination enthalten wird der Stapel bis zum aktuellen Stapelzeiger
  133. mit $BEEF aufgefüllt. (Dies ist der Fall, wenn das Programm vom CLI/Shell
  134. aus gestartet wurde.) Es somit nicht möglich festzustellen, wie groß der
  135. maximale Stapelverbrauch bisher gewesen ist.
  136.  
  137. Nach Abschluß dieser Vorarbeit wird nun laufend überprüft, wie weit das
  138. Füllmuster $BEEF noch unbeschädigt geblieben ist. Dies kennzeichnet die
  139. Stelle des bisherigen maximalen Stapelverbrauch. Der Vorgang wird abge-
  140. brochen, sobald das Programm endet oder CTRL-C gedrückt wurde.
  141. (Die Pause zwischen zwei Überprüfungen kann mit der DELAY-Option einge-
  142. stellt werden)
  143.  
  144. Nach Beendigung wird das Ergebnis der letzten Überprüfung ausgegeben.
  145. Sämtliche Zwischenergebnisse werden verworfen. Es ist daher gar nicht
  146. nötig, daß StackCheck während der gesamten Laufzeit des zu untersuchenden
  147. Programms seine Messungen durchführt.
  148. Wenn bekannt ist, wann das Programm endet, empfiehlt es sich StackCheck
  149. mit CTRL-C abzubrechen, sobald das Programm gestartet wurde. Kurz vor dem
  150. Ende des Programms muß StackCheck erneut aufgerufen werden. Wenn das Programm
  151. endet werden dann die gleichen Ergebnisse ausgegeben, als wenn StackCheck die
  152. ganze Zeit aktiv gewesen wäre.
  153. Bei Programmen, die von der Workbench aus gestartet wurden, genügt es sogar
  154. wenn StackCheck bei der Beendigung des Programms aktiv gewesen war. Es
  155. empfiehlt sich jedoch StackCheck auch bei Beginn zu aktivieren, damit die
  156. Nullen durch das zuverlässigere Füllmuster $BEEF ersetzt werden.
  157.  
  158.  
  159. DIE AUSWERTUNG DER AUSGABE VON STACKCHECK
  160.  
  161. Eine typische Ausgabe von StackCheck sieht folgendermaßen aus:
  162.  
  163. StackCheck V1.0 by Günther Röhrich
  164. This program is Public Domain. Press CTRL-C to abort.
  165.  
  166. Free stack area contained unknown pattern:
  167. 00290F58: 000A3EDF 00000FA0 00292454 00000001
  168. Stack OK:
  169. 00290F58: BEEFBEEF BEEFBEEF BEEFBEEF BEEFBEEF
  170. Stacksize: 4000
  171. Used max:  2818
  172.  
  173. Als erstes werden die ersten 16 Bytes beginnend vom unteren Ende des Stapels
  174. ausgegeben so wie sie von StackCheck vorgefunden wurden. Die Zahl vor dem
  175. Doppelpunkt gibt die Adresse des unteren Endes des Stapels an. Dann folgt zum
  176. Vergleich der gleiche Ausschnitt des Stapels wie er bei der letzten Über-
  177. prüfung ausgesehen hat. Sollte der Stapel "übergelaufen" sein wird ein
  178. entsprechender Hinweis ausgegeben. Es ist jedoch nicht möglich festzustellen,
  179. um wieviel der Stapel übergelaufen ist. Dann folgt die Angabe der Gesamtgröße
  180. des Stapels sowie der bisherige maximale Stapelverbrauch.
  181. Wenn StackCheck durch CTRL-C abgebrochen wurde wird zusätzlich die Größe des
  182. zum Zeitpunkt des Abbruchs benützten Stapels ausgegeben.
  183. Wenn festgestellt wurde, daß ein Stapelbereich außerhalb des von StackCheck
  184. angenommenen Bereichs benützt wurde, wird ein entsprechender Hinweis ausgegeben.
  185. (Möglich ist es z.B. mit Hilfe der StackSwap() Funktion der Exec-Library)
  186. Es ist jedoch nicht immer möglich dies festzustellen.
  187.  
  188.  
  189. PROBLEME
  190.  
  191. Eingangs wurde erwähnt, daß der Stapelverbrauch kurz nach Beginn und kurz
  192. vor dem Ende eines Programms nicht erfaßt werden kann. Wenn jemand selber
  193. ein Programm schreibt um es mit StackCheck zu untersuchen, so empfiehlt es
  194. sich am Anfang und Ende des Programms eine kurze Verzögerung einzubauen.
  195. (z.B. mit dem Befehl Delay(50)) Noch besser ist es, wenn der Start und
  196. das Ende des Programms eine Interaktion mit dem Benutzer beinhalten.
  197.  
  198. Unter Kickstart 1.2/1.3 sollte man nur Programme untersuchen, die von der
  199. Workbench aus gestartet wurden. Andernfalls kann es zu Abstürzen kommen.
  200.  
  201. Weiterhin ist die Untersuchung von BCPL-Programmen ab Kickstart 2.0 nicht
  202. möglich, da dies zu einem Absturz führt. (Es wird dabei ein Bereich im nor-
  203. malerweise unbenutzten Teil des Stapels benutzt. Dieser Bereich wird durch
  204. StackCheck mit $BEEF überschrieben.) Da BCPL-Programme ab Kickstart 2.0
  205. normalerweise nicht verwendet werden, habe ich darauf verzichtet gegen
  206. diesen Fehler etwas zu unternehmen.
  207.  
  208. Wenn Programme den unbenützten Teil des Stapels für irgendwelche Zwecke ver-
  209. wenden. (z.B. um selber einen Überlauf des Stapels feststellen zu können) kann
  210. es zu Problemen kommen. Wenn jemand ein derartiges Programm haben sollte so
  211. möge er/sie bitte mit mir in Kontakt treten. (ich selber habe keines)
  212.  
  213. Bei mehreren Abläufen eines Programmes kann es durchaus vorkommen daß StackCheck
  214. leicht abweichende Werte für den maximalen Stapelverbrauch anzeigt, selbst wenn
  215. das Programm stets die gleichen Aktivitäten durchführt. Dies ist kein Fehler von
  216. StackCheck, es hängt davon ab, zu welchem Zeitpunkt das Programm zwecks Task-
  217. Switching oder Interrupts unterbrochen wird. (In diesem Fall werden zusätzlich
  218. ca. 70 Bytes auf dem Stack abgelegt.) 
  219.  
  220.  
  221. ARBEITSWEISE DES STAPELS
  222.  
  223. Dieses Kapitel ist für diejenigen gedacht, die mit der Arbeitsweise des
  224. Prozessorstapels nicht vertraut sind. Assemblerprofis brauchen es nicht
  225. unbedingt durchzulesen.
  226.  
  227. Der Prozessorstapel der MC680x0 Prozessoren wächst von höheren Adressen
  228. in Richtung niedriger Adressen. Als Stapelzeiger dient das Register A7, das
  229. stets auf den letzten gültigen Eintrag auf dem Stapel weist. Um  Adress-
  230. fehler zu vermeiden wird das Register A7 auf einer geraden Adresse gehalten,
  231. selbst wenn nur ein Byte auf dem Stapel abgelegt werden sollte. Aus Kompatibi-
  232. litätsgründen wird dies ab dem 68020 immer noch eingehalten, obwohl es keine
  233. Adressfehler mehr geben kann.
  234. Der Stapel selbst kann beliebig groß werden, auf eine Einhaltung der Stapel-
  235. grenzen wird nicht geachtet. (Mit Hilfe einer MMU wäre dies jedoch möglich)
  236. Der Stapel dient zur Aufnahme temporärer Variablen sowie von Rücksprung-
  237. adressen des Prozessors bei Unterprogrammaufrufen. Außerdem wird im Falle
  238. einer Unterbrechung (Interrupt) der Zustand des Prozessors auf dem Stapel
  239. abgelegt, damit das Programm später an der gleichen Stelle wieder fortgesetzt
  240. werden kann.
  241. Auf dem AMIGA wird der Stapelzeiger bei einer Unterbrechung des Programms
  242. in der Variablen SPReg der Task-Struktur abgelegt. Das obere und untere Ende
  243. des Stapels steht in den Einträgen SPUpper und SPLower. (Gilt nicht immer bei
  244. Kickstart 1.2/1.3)
  245.  
  246.  
  247. ADRESSE DES AUTORS UND SONSTIGE HINWEISE
  248.  
  249. Da StackCheck Public Domain ist, steht es jedem frei Änderungen daran vorzu-
  250. nehmen oder es weiter zu verbreiten. Um eine Verwirrung unter den Anwendern
  251. zu verhindern halte ich es jedoch für ratsam, keine veränderten Versionen von
  252. StackCheck in Umlauf zu bringen ohne zuvor mit mir in Kontakt getreten zu sein.
  253. Wer einen Fehler finden sollte möge mich bitte informieren. Ich wäre ebenfalls
  254. dankbar, wenn jemand mir eine korrigierte Fassung der englischen Anleitung
  255. zuschicken würde, da es mit meinen Englischkenntnissen nicht gerade zum Besten
  256. steht. 
  257.  
  258. Adresse:
  259.  
  260.                  Günther Röhrich
  261.                  Lerchenbergstr. 4
  262.                  W-7300 Esslingen
  263.                   Deutschland
  264.  
  265.  
  266. Neue Adresse beginnend vom 1. Juli 1993:
  267.  
  268.                  Günther Röhrich
  269.                  Lerchenbergstr. 4
  270.                  73733 Esslingen
  271.                   Deutschland
  272.